OpenDaylight融合OpenStack架构分析

OpenStack和OpenDaylight（ODL）的融合是一个热门话题，有大量的文档可供参考，但是这些文章主要对其使用方面进行阐述，而没有讲如何实现OpenStack和ODL的融合。该篇文章将详细说明如何实现不同组件的融合。

ODL和OpenStack完整的安装步骤如下：

1、在虚拟机或者物理机上构建和安装合适的ODL版本（取决于你的选择）。确保你有合适的bundle实现Neutron的API（OVSDB、VTN Manager、LISP等）。

2、正确配置并启动ODL。

3、部署OpenStack。最好是多节点部署：一个控制节点，一个网络节点和若干个计算节点。

4、配置OpenStack，为ODL和OpenStack的融合作准备：

• 确保核心插件在模块化的二层组件（ML2）上。
• 将ODL作为“机制驱动”部署在ML2上。
• 配置ml2_conf.ini文件的[ml2_odl]区域：

Shell 1、username = admin 2、password = admin 3、url = http://IP-Address-Of-OpenDayLight:8080/controller/nb/v2/neutron

123	1、username = admin     2、password = admin     3、url = http://IP-Address-Of-OpenDayLight:8080/controller/nb/v2/neutron

5、在OpenStack上创建虚拟机，构建虚拟网络。

6、验证ODL界面生成的网络拓扑是否与想要的一致。

OpenStack和OpenDaylight融合

图1总结了OpenStack和ODL融合的全过程。Neutron包含ML2机制驱动，该机制驱动（ODL）作为REST代理能够调用所有的Neutron API。ODL包含北向REST服务（Neutron API服务），能够调用这些代理API缓存数据并可用于ODL的其他服务。下图详细地描述了这两个组件，这些RESTful API可以完成OpenStack和ODL的绑定。

图1:OpenStack和OpenDaylight融合

OpenStack

Neutron的模块化的二层组件（ML2）是一个可以使用二层网络多样性技术的框架。带有ML2插件的驱动程序实现了网络类型（local、flat、VLAN, GRE和VXLAN）的扩展和访问这些网络的机制驱动。

在ML2上，当添加、删除和修改三种核心资源（网络、子网和端口）的时候，将调用两次机制驱动。首次调用（也称为预提交调用）是为了维护机制驱动的状态，属于数据库业务的一部分。就ODL机制驱动而言，没有必要做这种预提交的操作。一旦业务被提交，机制驱动可以与外部服务和控制器交互的时候，其将被二次调用（也称为提交后调用）。

图2：ML2机制驱动架构

机制驱动在端口绑定过程中也发挥了作用：确定是否相关的机制可以为网络提供连接，如果可以，就使用相应的网段和VIF驱动。

图2总结了OpenStack Neutron的ML2机制驱动架构。ODL机制驱动由“mechanism_odl.py”文件和网络ODL驱动组成。基于ODL的API手册，机制驱动被分成了两个部分（核心API和扩展API），ODL机制驱动和ODL驱动类实现了核心API，ODL的3层路由插件类只实现了扩展API。目前，ODL驱动不支持防火墙服务（FWaaS）和负载均衡服务（LBaaS）。

ODL机制驱动接收到调用消息后，就对核心资源（网络、子网和端口）进行相应的添加、删除和修改的操作，机制驱动通过调用同步函数将消息转发给ODL驱动类，该同步函数采用了‘sendjson’ API。

同样地，ODL的3层路由插件类利用3层的API添加、删除和修改路由和浮动IP。因此，核心API和扩展API都调用‘sendjson’ API向ODL控制器发送REST请求，并等待应答。

之后的章节会介绍ODL是如何处理这些REST调用的。

OpenDaylight

OpenDaylight暴露OpenStack Neutron API服务接口，给多样性的解决方案提供Neutron API操作。图3总结了OpenDaylight Neutron API的实现架构，Neutron API服务主要由三个bundle组成：北向API和南向接口（SPI）、转录器（transcriber）以及解决方案的集合。

图3：OpenDaylight Neutron API实现架构

Northbound API Bundle

OpenDaylight的北向API处理来自OpenStack插件的REST请求并作出合适的应答。该bundle的组成部分如下：

1、父类请求： IneutronRequest。

2、JAXB(Java architecture for XML Binding)带注释的request类的集合，这些类涉及到的资源有：网络、子网、端口、防火墙和负载均衡等，这些request实现了IneutronRequest接口。例如：网络request包含如下属性：class NeutronNetworkRequest implements INeutronRequest

Shell @XmlElement(name="network") NeutronNetwork singletonNetwork; @XmlElement(name="networks") List<NeutronNetwork> bulkRequest; @XmlElement(name="networks_links") List<NeutronPageLink> links;

123456

@XmlElement(name="network")    NeutronNetwork singletonNetwork;    @XmlElement(name="networks")    List<NeutronNetwork> bulkRequest;    @XmlElement(name="networks_links")    List<NeutronPageLink> links;

3、Neutron北向类的集合：为管理资源提供REST API。例如：NeutronNetworksNorthbound 类包括如下API：listNetworks(), showNetwork(), createNetworks(), updateNetwork()和deleteNetwork()。

除非特别提及，symbol*类都表示如下资源：网络、子网、端口、路由、浮动IP、安全组、安全组规则、负载均衡、负载均衡监测、负载均衡监听器和负载均衡资源池等。

Neutron SPI Bundle

Neutron SPI是连接北向API到实现方案的重要bundle，这个bundle包括：

1、JAXB (Java architecture for XML binding)注释的基类和子类。这些类以Neutron*命名，支持v2.0版本的API文档。

2、INeutron*CRUD接口。这些接口通过转录器（transcriber）实现。

3、INeutron*Aware接口。这些接口通过特定的插件（OpenDove、OVSDB、VTN等）实现。

Transcriber Bundle

Transcriber模块包含Neutron*类，这些类通过实现INeutron*CRUD接口将Neutron对象缓存下来。其中，大部分的类都包含一个并发的HashMap。如private ConcurrentMap portDB = new ConcurrentHashMap()，所有的添加、删除和获取的操作都在HashMap上进行。

Implementation Bundle

OpenDaylight的优势在于其包含Neutron网络的多种实现方式，提供多种与OpenStack结合的方法。ODL的北向服务能够提供网络虚拟化，这一功能可以作为Neutron网络的一种实现方案。ODL用于Neutron API实现的插件包括：

1、OVSDB：OpenDaylight将其北向API与Neutron结合，使用OVSDB对计算节点的虚拟交换机进行配置。所以ODL可以管理网络连接，还可以为计算节点开通GRE或者VXLAN隧道。OVSDB Integration是一个可以实现Open vSwitch数据库管理协议的bundle。该管理协议是网络虚拟化中Open vSwitch转发数据需要的重要协议。虚拟化版本中的OVSDB neutron bundle支持使用VXLAN和GRE隧道部署OpenStack和CloudStack的网络虚拟化。

2、VTN Manager（Virtual Tenant Network）：VTN manager是网络虚拟化的一种解决方案，实现了一个使用AD-SAL的控制器的OSGI bundle，可以管理OpenFlow交换机。VTN manager还有一个单独的组件为OpenStack提供网络服务。VTN manager的Neutron组件能使OpenStack运行在单纯的OpenFlow环境下，因为数据平面所有的交换机都支持OpenFlow。VTN manager还可以使用OVSDB-enhanced VTN。Neutron bundle可以使用OVSDB插件进行添加端口等操作。

3、Open DOVE：Open DOVE是一个“网络虚拟化”平台，控制平面使用OpenDaylight，数据平面基于Open vSwitch。Open DOVE的目的在于供2层或3层的多租户网络建立连接，它运行在虚拟数据中心的所有IP网络上。据IBM研究，Open DOVE是基于IBM SDN虚拟环境和DOVE技术的。Open DOVE在氢版本发布之后就再没有更新过，无疑它在ODL锂版本上的扩展性受到了限制。

4、OpenContrail (plugin2oc)：为OpenDaylight控制器和OpenContrail平台提供交互。开源解决方案的结合使得OpenContrail具备了一些功能，例如：OpenDaylight项目的云网络和网络功能虚拟化（NFV）。

5、LISP Flow Mapping
LISP（Locator/ID Separation Protocol）目的在于提供一个灵活的map-and-encap框架可以为overlay网络应用程序所使用，并将网络的控制平面与数据转发平面分离。LISP包含两个namespace：endpoint identifiers (EIDs — 主机的IP地址)和routing locators (RLOCs —连接主机的LISP路由的IP地址).LISP流映射提供了LISP映射系统服务来存储数据（包括路由策略和负载均衡等）。

这些解决方案实现了以下部分或全部的功能：网络、子网、端口、路由、浮动IP、防火墙、防火墙策略、防火墙规则、安全组、安全组规则、负载均衡、负载均衡监测、负载均衡监听器、负载均衡资源池和负载均衡资源池成员。这些处理程序支持对核心资源（网络、子网和端口）进行相应的添加、删除和修改的操作。例如：NeutronNetworkHandler实现了如下操作:

Shell canCreateNetwork(NeutronNetwork network) neutronNetworkCreated(NeutronNetwork network) canUpdateNetwork(NeutronNetwork delta, NeutronNetwork original) neutronNetworkUpdated(NeutronNetwork network) canDeleteNetwork(NeutronNetwork network) neutronNetworkDeleted(NeutronNetwork network)

123456

canCreateNetwork(NeutronNetwork network)    neutronNetworkCreated(NeutronNetwork network)    canUpdateNetwork(NeutronNetwork delta, NeutronNetwork original)    neutronNetworkUpdated(NeutronNetwork network)    canDeleteNetwork(NeutronNetwork network)    neutronNetworkDeleted(NeutronNetwork network)

南向插件的使用决定了机制的选择：OpenFlow（1.0或1.3）、OVSDB、LISP、REST（OpenContrail）等。举一个VTN Manager中ManagerNeutronNetworkCreated handler的例子，参与处理程序的步骤总结如下：

1、检查是否可以通过调用canCreateNetwork再次创建网络。

2、将Neutron网络的租户ID（tenantID）和网络ID（network ID）分别转变成租户ID（tenant ID）和网桥ID（bridge ID）。

3、检查租户是否已经存在，否则就创建一个租户。

4、创建网桥并执行VLAN映射。

实际的操作流程是VTN manager的Neutron组件调用前者的核心功能，使用OpenFlow（1.0）插件逐个配置OpenFlow交换机。

使用所有的bundle创建网络

图4：在OpenDaylight上创建网络的过程

图4简要地总结了网络创建的过程和上述OpenDaylight Neutron实现方案中bundle的调用。该图帮助读者理解所有bundle中的控制流。

总之，OpenDaylight是与OpenStack融合的最优控制器之一，虽然暂不支持负载均衡和防火墙服务，但多种免费的解决方案和完整的核心API对管理员来说有巨大的优势，带来了很大的灵活性。我们期待在不久的将来OpenDaylight能够支持OpenStack的所有扩展，实现二者的完美融合。